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1 . 2 SCOPE 

This document specifies a Media Independent Interface. This 
interface uses standards current in the industry. The 
industry standards were generated at different times and 
have differing applications. This has lead to a convoluted 
and poorly defined set of interface primitives. They lack a 
cohesive binding to each other. In addition the standards 
do not describe the physical aspects of these standards 
which would allow different implementations of them to 
operate in concert. The Mil ICD binds these standards by 
integrating mechanical, electrical, and functional interface 
standards within this document. 

The Mil is described in hierarchical fashion. At the base 
are IEEE /ISO documents (standards) which describe the 
functionality of the software modules or layers and their 
interconnection. These documents describe primitives which 
are to transcend the Mil. They do not describe the method 
by which layers communicate or the exact language in which 
they speak. In addition different specs sometimes disagree 
in the structure of the same primitives. These standards 
specify the logical interface. 
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These logical - specif ications are further defined in this ICD 
with the use of a canonical language. This canonical 
language along with the physical and electrical 
specifications called out in this document provide the final 
binding required to make a working interface. 

The structure of this standard is pictured above. 


1 . 3 ABBREVIATIONS 


ASN.l - Abstract Syntax Notation One 

CPU - Central Processing Unit 

DIS - Draft International Standard 

ICD - Interface Control Document 

ICI - Interface Control Information 

IEEE - Institute of Electrical Electronics Engineers 

ISO - Internation Standards Organization 

LAN - Local Area Network 

LLC - Logical Link Control 

MAC - Media Access Control 

Mil - Media Independent Interface 

OSI - Open Systems Interconnection 

PDU - Protocol Data Unit 

SDU - Service Data Unit 

SM - Station Management 


1 . 4 DOCUMENTS 

ANSI X3T9/84-100 Fiber Distributed Data Interface ( FDDI ) 

IEEE 802.1 (still draft) Network management 

IEEE 802.2 or ISO 8802/2 Logical Link Control (LLC) 

IEEE 802.3 or ISO 8802/3 Carrier Sense Media Access 

(CSMA/CD) 

IEEE 802.4 or ISO 8802/4 Token Bus 

IEEE 802.5 or ISO 8802/5 Token Ring 

IEEE 802.7 or ISO 8802/7 Slotted Ring 

IEEE P1014/D1 . 0 VMEbus/ Signetics VMXbus 

ISO DIS 8824 Specification of Abstract Syntax Notation 

ISO DIS 8825 Basic Encoding for Abstract Syntax Notation 

ISO 7498 ISO OSI Basic Reference Model 

ISO 7498 DAD1 connectionless Data Transmission 

ISO DP 7498/4 Management Framework 

Sperry Report 2055-04 thru 2055-8 
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2 GENERAL 

The intent of the Mil is to provide a universal interface to 
one or more MACs for the Logical Link Controller and Station 
Manager. This interface includes both a standardized 
electrical and mechanical interface and a standardized 
functional specification which define the services expected 
from the MAC. 
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3 ARCHITECTURE 


3 . 1 INTRODUCTION 


Communication between computers has always been difficult 
when a common design was not used for all the computers. It 
has become necessary to provide a means whereby dissimilar 
computers communicate. To supply that need IEEE created a 
number of standards which could be built by different 
designers and yet could pass information between them. The 
information passed between them was also slightly dissimilar 
in content and structure and again there was a need for 
another standard. The International Standards Organization 
(ISO) built a 7 layer model by which the control of 
information passing could be standardized. The model 
adopted the IEEE standards. These IEEE standards are the 
first two layers of a 7 layer implementation where the 
lowest layer is the physical connection between the 
computers . 
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Figure 1.0 The ISO OSI model 
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The IEEE standards used in this document are used in the 
lower two layers of the ISO OSI model above. These layers 
are sub-divided by the IEEE standards. 
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Figure 2.0 The IEEE Model 

The IEEE committee realized the need to be able to use a 
common Logical Link Control for several versions of the 
Media Access and Physical layers. The IEEE standards 
provide compatibility only on a logical level. They do not 
describe the implementation. There are inconsistencies 
between MACs. Some MACS provide more services than others. 
This makes standardized interchanges difficult even on a 
purely logical level. Finally the initialization and 
maintenance of the MACs are considerably different which 
complicates the matter further. 


The purpose of the Mil is to allow standard interchanges 
between the MACs and the LLC. The interchanges requires a 
Station Manager which can effectively operate the entire 
selection of MACs. Fortunately they're all similar in their 
management and all of them tend to operate without a lot of 
external intervention. 
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3.2 HOW THE ARCHITECTURE WORKS 

Two kinds of information must be passed in order to move 
data between the LLC and MAC; the data to be shipped and 
shipping instructions. 

The instruction part of this information is called Interface 
Control Information (ICI) and is layer to layer 
instructions. It includes instructions as to where this 
data can be found, its sender and receiver,, and its 
quantity. The Mil instructions are limited to a standard 
set of primitives ( MA_DATA . Request , MA_DATA . Confirm , 
MA_DATA . Indicate) . These primitives and their effect are 
defined in the IEEE standard. The specification is a 
logical one and does not attempt to provide guidance as to 
its implementation. In this ICD, the primitives have been 
re-written in a standard syntax and encoding for 
implementation clairif ication . Where primitive parameter 
differences between MAC standards occur, the syntax provides 
the layers an ability to default missing parameters and 
ignore extra ones. If a LLC has the capability to use all 
the services of a MAC, then the interface will allow it to 
do so. If not, then it must depend on the non-optional 
primitive parameters and rely on the MAC to default any 
additional ones. 

The Data information to be shipped is called the Protocol 
Data Unit (PDU) and contains the original message and peer 
to peer layer messages. Both the data and the peer layer 
information has no direct effect on the operation of the 
Mil. It simply must be passed intact across it. 

To provide a physical means to implement the above activity, 
an architecture has been selected which can be supported 
with an existing standardized bus. The architecture is as 
follows ; 
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Figure 3.0 The Logical Model 

This model does not restrict the MAC, SM and LLC except that 

they must be able to access common memory in order to 

communicate. Data flow is always directed through this 
common memory element. If an implementation of the MAC has 
its communication channel located on-board as locally and 
globally decoded dual ported memory then it will have a 

speed advantage. It will be able to read and write to this 
part of the common memory with a local access and detect 
global reads and writes via local interrupts. This 
eliminates one of two parties from having to arbritrate for 
the bus . 

Each sending entity knows the address of the receiving 
entity channel. Any time a entity wishes to pass 

information to another entity, it simply writes the address 
of the information into the receiver's channel (address). 
If the receiving channel's memory location is decoded on 
board, the receiving entity's physical device and the 
pointer will be read with a local access . 

Local decoding of the receive channel is not required. The 
channels physical implementation is two valid memory 
locations in common memory, which could be in regular memory 
(i.e. as dual port memory or mapped to read/write 

registers). Any standard CPU card with the ability to read 
and write global memory, will be able to implement a 
receiving channel. 
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Figure 4.0 The Data Flow Model 

The Mil data flow diagram shows that the Mil is actually a 
bus with channels of communication. The channels are two 
sequential address locations mapped in the common (sometimes 
called global) memory map. These address locations provide 
the same hardware services that are found in standard VME 
memory (i.e. long addressing, DTACK , Buserror, etc). The 
first location is tested to see if the channel is busy. If 
not then the address of data to be passed is written to the 
second memory location. The entity receiving the date uses 
the address as a pointer to the information stored in global 
memory and subsequently resets the channel busy location. 
The busy location is known as the channel semaphore. 

The address passed via the channels is the Interface Control 
Information (ICI). The ICI contains information as to the 
location of Protocol Data Units (PDU). The ICI primitives 
are described in the IEEE specifications and their syntaz 
and encoding structure is described in this document. 

This Mil architecture is implemented on a standard bus which 
uses a multi-master architecture. It has various options, 
all of which are allowable in the Mil. The system designer 
need only be concerned with the performance resulting from 
his choices of entity designs and bus options. Choices such 
as the size of the common memory available to the MAC for 
PDUs are not restricted by the Mil. The designer is free to 
choose between MACs with any amount of on board buffering. 
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There may be MAC designs which have no on-board buffers and 
require the card to be set to preempt bus users when packets 
arrive . 

The only restrictions imposed by this Mil ICD are the use of 
VMEbus, enough common memory between users to implement the 
channels and store ICIs and PDUs , and the use of the 
standard primitive syntax as defined in this document. 


3.3 Mil HIGHLIGHTS 

The Mil solutions given in this ICD are the result of a 
unique blend of advanced technology integrated with the ever 
expanding world of standards. This integration is made 
possible by the careful selection of the hardware platform 
and specialized development of software interface 
technology. The Mil ICD is the product of a continuous 
effort in the advancement of state of the art 
communications. The feasibility of the Mil ICD was 
demonstrated by two fiber optics developments which have a 
media bandwidth that exceeds most of current industry 
implementations by a factor of ten. 

Even more important is the Mil ICDs unique ability to grow 
with technology. Its method of information exchange was 
explicitly developed and exercised to establish a decisive 
interface. This interface was adapted to two disimilar 
Media Access Controllers running at 100 M-bit/s in order to 
illustrate its capacity to meet and exceed the needs of 
custom and standard users alike. As the communication 
industry realizes ever increasing sophistication in 
communication functionality, the Mil ICD will continue to 
demonstrate its flexibility. 
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The Mil; 

o uses IEEE, ISO and VMEbus Standards, 
o is useable for both ground and flight systems, 
o provides complete interchangeability between MACs , 
o supports bridges, routers, and gateways, 

o allows changes in the LLC , SM, or MAC, 

o is expandable yet retains backwards compatibility, 
o does not interfere with upper layer software, 
is standard mechanically, electrically, and 
functionally, 

and defines mechanical, electrical and functional 
aspects . 


o 
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3 . 4 SYSTEM REQUIREMENTS 

A system supporting a Mil must contain at least one VMEbus, 
enough, globally addressable memory and bus bandwidth to 
allow operation of the LLC , SM, and MAC entities. At 
minimum, the bus must have enough slots and capacity to 
provide Master capacity for the VME card(s) containing the 
MAC, SM and LLC entities. 
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Figure 5.0 Example Configuration 


Selection of VMEbus options such as round robin arbitration 
or priority arbitration is not limited by the Mil and is up 
to the system designer. These options are all allowable 
providing all devices are consistent with the VMEbus 
specification. 
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3 . 5 INTERFACE CONTROL SCOPE 

The Mil ICD was design to allow multiple cards for each 
entity (MAC, LLC , SM) and multiple entities (LLC and SM) per 
card. For example if a MAC design requires a large memory, 
a second card can be used to support it. The addressing of 
that card would have to be compatible with the whole system. 
If mapping or speed is a problem, then the VMX bus might be 
used. There are no restrictions along these lines. 

The number of entities across the Mil is not restricted. 
The ability of the entities to respond or even recognize 
different combinations of entities is left open for the 
implementor. For instance the Mil was designed to allow 
multiple MAC entities per LLC. The interface will support 
two or more LLCs with matching MACS. Multiple LLCs or SMs 
per MAC is supported. The System designer is responsible* 
for insuring that the devices are compatible and that 
combinations and quantity are appropriate for the design. 
The Mil does not limit the design of any of the entities 
except to insure that they can communicate in a known 
manner. The Mil contains an inherent flow control which 
will eliminate overrun of Mil interfaces. The sustained 
data rate across the Mil is limited only by the bandwidth of 
the VMEbus and the size of memory allowed on the VMEbus . 
Speed of the entities and their ability to effectively use 
the bus is considered a system design issue beyond the scope 
of the Mil requirements. 



Mil ICD Program 
ARCHITECTURE 


Page 15 
21 July 1987 


3.6 MECHANICAL AND ELECTRICAL 

The Mil relies on the VMEbus and VMX specification to 
provide the electrical and mechanical platform on which Mil 
resides. VMX interface is allowed to enhance system 
performance. It is considered an extension of the VMEbus 
and the Mil devices must conform to the same Mil 
requirements whether a VME or VMX operation is being 
performed. 

The following is not specified or limited by the Mil; 

o Bus addressing and priority, 
o physical slot location, 

o the number of physical cards, 

o the division of functionality between cards, 
o the amount of memory, 

o the use of DMA processors and support devices. 
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3 . 7 SOFTWARE 

The software aspect of the Mil is a virtual interface. The 
Mil users are configured to recognize other Mil entities by 
addresses only. Entities using the Mil are made aware of 
the other devices addresses either by mechanical means (dip 
switches, proms, etc) or by software interaction. 

The Station Managers role is to provide information to the 
LLC and MAC which will allow operation in the system 
environment . In a typical software environment memory 
allocation is controlled by the operation system. The 
memory used by Mil users is allocated by the Station Manager 
and given to the users via the Mil ICD method. This avoids 
standardizing an operating system just to assure correct 
memory usage. In addition to common memory allocation to 
Mil users, the Station Manager provides addresses to the* 
user entities which indicate channel locations. Each Mil 
user entity has the capacity to receive initialization 
information upon startup according to the Mil prescribed 
method . 

The Mil transfers information by passing pointers to data 
structures located in common memory. The MAC has two 
receive channels to receive the pointer addresses from the 
Station Manager and LLC. The LLC and SM have a single 
receive channel each to receive pointer addresses from the 
MAC. Receiving channels beyond these required ones are not 
defined by the Mil ICD and are beyond its scope. 


Transmitting occurs only after a non-interrupting test and 
set is made of the channel semaphore location and ownership 
to use the channel is established. The entire transmission 
involves a write of a single long word address into the 
memory location following the semaphore ( semaphore_address + 
1 (long address)). These locations are shown in figure 7.0. 
See the VMEbus Specifications for address length 
definitions. The logical flow of access to a receive 
channel is diagramed as follows; 
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Figure 6.0 


SETTING THE SEMAPHORE BIT 

The VMEbus provides a read-modify-write capacity which 
should be used to implement the channel semaphore. The Mil 
ICD requires the use of the semaphore in order to allow 
multiple users to access the same channel and avoid 
collisions. To give an example, if there are two parts of 
the LLC which have the ability to use a single MAC channel, 
then the owner of the channel must be established before it 
can be used. Otherwise both might attempt to use the 
channel at the same time. Any time one or more asynchronous 
devices wish to share a channel this decision must occur. 
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The winner of the right to own the channel is given to the 
one who first test and sets a bit within the confines of a 
single bus access. This bit is a semaphore bit and is 
called the channel busy bit. Each user tests the busy bit. 
If the test indicates that the channel is not busy then it 
sets the channel busy and uses it. The read-modify-write 
bus cycle is used because a problem may arise if two devices 
or entities test the busy bit at the same time before either 
has had the chance of setting it. Both would think that it 
was the owner of the channel. If the bit is tested and then 
set in a single non-interrupting bus access then no other 
device can test at the same time. Since it was tested and 
set in the same operation then a false indication says that 
it was previously not set and your the one who set it , 
therefore your the unique owner. The loser will test the 

bit as true, meaning the bit was previously set and it 
simply set it again. The Test-and-Set (68000) instruction* 
has been used as an example because it typically causes the 
read-modify-write cycle on the VMEbus. It is not the only 
method which will insure proper semaphore testing. 

RESETTING THE SEMAPHORE BIT 

The Mil channels are virtual interfaces and its actual 
implementations are transparent to the users. The detection 
and reset of the Semaphore bit is not specified by the Mil 

and is left to the designer of the receiving entity. The 

Mil allows the channel locations to be anywhere in the 

common memory map and therefore allows the designer to 
provide on board decoding of the semaphore location and its 
associated pointer. Such an implementation would appear to 
the Mil bus as simple memory locations, but actually could 
be local memory and access might result in a local 
interrupt. The receiving channel could be located on a 
standard memory card and the semaphore bit polled by the 
receiving entity. To avoid the receiver and transmitter 
interleaving access to the channel, the address following 
the semaphore location could contain a pointer to itself. 
When the pointer is overwritten then the location can be 
considered valid. 

The receiving entity is expected to reset the busy bit after 
it no longer needs the address passed to it . 

The address passed to the receiver is a pointer to a record. 
This record will contain another address to another record 
like itself. When each record points to another record, it 
is referred to as a linked list. The last link in the list 
points to itself. Each record contains information written 
in a format as described in the Encoding section of this 
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document . 


The channels are shown below: 
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Figure 7.0 Mil Memory Maps 


-* 


MAC Memory Map Descriptions 

SM_RDY bit - SM test this bit before writing into SM_REC 

SM_REC ptr - SM writes pointer to link list of SM commands. 

LLC_RDY bit - LLC test this bit before writing into LLC_REC 

LLC_REC ptr _ LLC writes pointer to link list of LLC ICI 

primitives . 

LLC Memory Map Descriptions 

MAC__RDY bit - MAC test this bit before writing into MAC_REC 

in the LLC memory map. 

MAC_REC ptr - MAC writes pointer to link list of MAC 

ICI primitives. 

SM Memory Map Descriptions 

MAC_RDY bit - MAC test this bit before writing into MAC_REC 

in the Station Manager memory map. 

MAC_REC ptr - MAC writes pointer to link list of MAC 

ICI primitives. 
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3 . 8 SYNTAX - 


The common set of primitives to be used by Mil . ar ® ± 

with a syntax which is itself a standard. This standard is 
ISO 8824 ASN.l. The primitives and encodings are shown in 
the Primitive Syntax and Encoding section of this document 
The primitives between the MAC and the LLC are rigidly 
defined and are common between the different MAC standards. 
The primitive descriptions were structured in such a way as 
to take advantage of useful options in t 
priorities, linking, etc) and to allow for future growth 


3 . 9 ENCODING 


The encoding used in the Mil ICD can be found 

_ . too ACT ci+arwiarn 


ASN 

ASN 

the 


in ISO 8825 „ 

1 encoding. It is the ISO OSI standard encoding for the 
1 syntax. This encoding for ASN.l has been adopted * 
Mil because it is an established and wel 
standard As encoded, the Mil primitives have been 

optimized for size and complexity. The encoding inclu es 
length bits which are only useful to the Mil ^ 

confusion as to the quantity of information embedded 

single primitive. 
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3.10 CHANNEL RULES 

A channel consist of two locations mapped to memory which is 
common to all entities on the Mil. Both locations wxll be 
suunorted globally as read/write memory locations. 
fi?st location is the semaphore location and the i second 
location is the Link location. Both address l° Gata °f 
respond to Long addressing as specified m the VMEbus 
specification. The Rules for channel operation are simple, 

1) To use a channel; A non-interrupting test and set of the 
semaphore bit must be performed before each access to the 
location which follows it. This bit must test as not se 
before the set bus cycle occurs in order to claim access * 
it . In no other case can a write be made to the loca 
following the semaphore. 

2) The semaphore bit to be tested is the high order bit of a 
the lowest order byte as defined in the VMEbus 

specification. The bus access must be a r ^ d :“° d ^^^cle 
bus cycle and is left to the implementer as to how the cycle 
is invoked ( such as a Test & Set with a 68k series CP ) . 

3) A bus write of the location following the semaphore 

location will be supported as a normal VMEbus memory access 
( DTACK or BUSerror). Indiscriminate reads may not provide 
accurate answers. Once written to, owner ^ lp itten by 

is no longer valid and the location may be oveTVTitten cy 
the receiving entity. Transmitting entities should conside 
it a write only location. 

4) After a successful claim to the channel as outlined in 
item 1 a SINGLE write is allowed to the link ^ caPa0 “ r ™® 

information written is to be an address repeated 
can be found. After writing it, item 1 must be repe 

before the channel can be accessed again. 
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3.11 PRIMITIVES 

3.11.1 MAC/LLC PRIMITIVES - 


3.11.1.1 COMMANDS - 


The LLC Interface supports MA_DATA request and .f^-Hf^hese 
MA DATA indication and MA_DATA . indi_acks . Details of these 
commands are described in the IEEE 802.3 and IEEE 802.2 
documents. A brief explanation follows; 


¥ A DESTINATION_ADDRESS , M_SDU , DESIRED_QUALITY } 

* 

This command comes from the LLC to the MAC r ® p tes®nts a 

reauest to ship the data pointed to by the M_SDU to the 
station at address DESTINATION .ADDRESS using a level of 
quality of DESIRED.QUALITY . The MAC is expected to respond 

with the following command; 


MA JDATA . CONFIRMATION 
{ QUALITY, STATUS } 


This 

LLC 

been 


command from the MAC to the 
that the data previously 
sent . 


LLC will indicate to the 
requested to be shipped has 


MA_DATA. INDICATION 

{ DESTINATION_ADDRESS , SOURCE_ADDRESS , 
M_SDU , QUALITY ' 


This command from the MAC to the LLC will station 
up that data located at pointer M_SDU from the statio 

SOURCE_ADDRESS was sent to DESTINATION_ADDRESS ( “®®£® TY ° 
identify when a group address is used) with a QUALITY or 
service The MAC expects the LLC to overwrite the 
MAJ 3 ATA. INDICATION with the MA_DATA . INDI_ACK thus allowing 
it to release the message buffer. 


MA_DATA . INDI_ACK 
{ STATUS } 


This 

MAC 


jmmand from the LLC to the MAC will indicate to the 
lat the LLC has no more use for the indicate mes g 


buffer . 
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3.11.1.2 SYNTAX - 


The LLC communicates to the MAC across the MI ** omTor 

i o written according to Abstract Syntax Notation One 
ASH.l (ISO DIS 8824). The inf. ormation descr i bed is . 

to the basic coding rules as found m ASN.l (I 
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Message_record [PRIVATE 0] CHOICE 

\ ma_data_ request [0] Mo_request_t ype t 

ma_data_conf i rm [1] Ma_conf i rm.type ! 

ma_data_i nd i cate [2] Ma_i ndi cate-type I 
ma_ i nd i _ack [3] Ma_i nd i _ack_type 


Ma request_type : SET 


| de s t i na t i on_add r e ss 
M_SDU 

request ed_Se r_c lass 
f rame_cont ro I 
s t ream 
I i nk_ I i st 
token_c I ass 


[0] Net_address_type 

[1] M_SDU_type 

[2] Req_ser_type 

[3] Frame_con_type 
1^1 St ream_type 

[5] L i n k I i st_type 

[6] Token_c I as s_ type 


(opt i ona I ) 
(opt i ona I ) 
(opt i ona i ) 
( opt i ona I ) 


I 


Ma_i nd i cate-type ::=SET 

$ dest i nat i on_address [0] Ne t_address_ty pe 
source_address [1] Net_address_type 

M SDU [2] M_SDU_type 

recept i on_status [3] Rec.status (optional) 
requested_Se r_c lass [4] Req_ser_type (optional) 
frame.control [5] Frame_con_type (optional) 

I j nk_ list [6] Li nk_l i st_type (optional) 

The optional parameters have a default value. 


T ron_status 

Provided_ser_type (optional) 
Number_of_sdu (optional), 

Li nk_l i st_type (optional) 


Ma_i ndi_ack_type ::= SET 

\ indi_status [0] Integer, — 1 « good 0= not accepted 
I i nk_ list [2] Link_l ist.type (optional) 

\ 

Net_add ress_type : CHOICE 

, net_add_16 Va I ue_i nteger_1 , 16 bit address option 

net_add_48 Value_intege r_48 - 48 bit address opt.on 


M_SDU_t ype : := SET 
\ SDU_PTR [0] Address, 

SDU.SIZE [1] INTEGER, 

buff.num [2] INTEGER 


Ma_conf i rm_type : := SET 
[ t ransmi t_stat us [0] 

prov i ded_se r_c I ass [I] 

numbe r_of _sdu_ I i nks [2] 

I i nk_ list [3] 

\ 
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Req_se r_t ype : : = 

SET 


| priority 

[0] 

INTEGER 

response 

[1] 

INTEGER 

qua 1 i ty_of _ser 

[2] 

INTEGER 
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, (opt i ona I ) 

, (optional) — ack = 1 
(opt i ona I ) 


Prov ided_ser_type : := SET 

\ priority [0] INTEGER, (optional) 

response [1] INTEGER, ( opt i ona i ) — ack = 1 

quol i ty_of_ser [2] INTEGER (optional) \ 

I nd i _ack_type : := SET 
| i nd i _a c k_s t a t us Ack_status ( 

F rame_con_type : := SET \\ -TBD 2 octets, see FDD I 5.4.1 
L i n k I i s t_t y pe : := SET )Address( 

St ream_type : SET ^INTEGER* — 1= multiple M_SDUs xmitted 

See FDD I 


Token_c I ass_t ype : := SET )INTEGER| TBD 
Rec_status : := CHOICE 

\ status [0] INTEGER — 1 * 90 od , all else bad. 

\ 

Tran_status : — CHOICE 

) status [0] INTEGER — 1 = good, all else bad. 

\ 

Numbe r_of _sdu : CHOICE { I NT EGER f - Number of M.SDUs 
t ransmi t ted 
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3.11.2 STATION MANAGER - 


3.11.2.1 COMMANDS - 


The Station manager sends invoke commands to whtch^ollow 
MAC responds with a reply response . P & MA c 
are first station manager command followed by 

response . 


SM_MAC_LM_SET_VALUE . INVOKE 
SM_MAC_LM_SET_VALUE . REPLY 


SM_MAC__LM_GET_VALUE . INVOKE 
SM_MAC_LM_GET_VALUE . REPLY 


SM„ 

SM_ 


MAC LM_COMPARE_AND_SET_VALUE . INVOKE 
MAC_LM_COMPARE_AND_SET_VALUE . REPLY 


-# 


SM_MAC_ ACT ION_ VALUE . INVOKE 
SM_MAC_ACTION_ VALUE . REPLY 


The Station manager can set an event mask which 
MAC to report events without a direct T^est^ 
initiate a NOTIFY and expects a REPLY from 
response . 


allows the 
The MAC can 
the SM in 


SM_MAC_EVENT_VALUE . NOTIFY 
SM_MAC_EVENT„VALUE . REPLY 
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COMMAND DESCRIPTIONS 


SM_MAC_LM_SET_VALUE . INVOKE 
{ PARAMETER_TYPE , ACCESS_CONTROL_INFO \ 

The objective of the SM_MAC_LM_SET_VALUE . INVOKE command by 
the SM is to set a value in the MAC as defined by the 
parameter_type structure. This structure specifies both the 
variable to be set and the value to which it is set. 

SM„MAC_LM_SET_VALUE . REPLY 
{ STATUS } 

The objective of the reply by the MAC to the SM is to 
indicate the success or failure of a previous, 
SM_MAC_LM_SET_VALUE . INVOKE . The SM expects the MAC to 
overwrite the SM_MAC_LM_SET_VALUE . INVOKE with the 
SM_MAC_LM_SET_VALUE . REPLY thus allowing the SM to release 
the message buffer. 


SM_MAC_LM_GET_VALUE . INVOKE 
{ PARAMETER_TYPE , ACCESS_CONTROL_INFO } 

The objective of the SM_MAC_LM_GET_VALUE . INVOKE command by 
the SM is to get a value in the MAC as defined by the 
parameter_type structure. This structure specifies the 
variable to be read. 

SM_MAC_LM_GET_VALUE . REPLY 
{ PARAMETERJTYPE , STATUS } 

The objective of the reply by the MAC to the SM is to 
indicate the success or failure of a previous 
SM_MAC_LM_GET_ VALUE . INVOKE . The SM expects the MAC to 
overwrite the SM__MAC_LM_GET_VALUE . INVOKE with the 
SM_MAC_LM_GET_ VALUE . REPLY thus allowing the SM to release 
the message buffer. 


SM_MAC_LM_COMPARE_AND„SET_VALUE . INVOKE 
{ PARAMETERJTYPE, 

OPERATION_COMMAND , 
ACCESS_CONTROL_INFO } 
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The Compare- and Set value command forces the MAC to do a 
comparison (of either a given constant or of a MAC variable) 
against a MAC variable. If the comparison is true then the 
MAC variable is over written. The PARAMETER_TYPE indicates 
the parameter to be over written and the value to use. The 
OPERATION_COMMAND structure specifies the comparison to do, 
and the constant or MAC variable to use in the comparison. 


SM_MAC_LM_COMPARE_AND_SET_VALUE . REPLY 
{ STATUS , RETURN_VAL } 


The objective of the reply by the MAC to the SM is ^ 
indicate the success or failure of a previous 
SM_MAC„LM_COMPARE_AND_SET_VALUE . INVOKE . The SM e^P^cts 
MAC to overwrite the SM„MAC_LM_COMPARE_AND_SET__VALUE . INVOKE 
with the SM_MAC_LM_COMPARE_AND_SET_VALUE . REPLY thus allowing 
the SM to release the message buffer. 


SM_MAC_ACTION_VALUE . INVOKE 
{ PARAMETER_ID , ACCESS_CONTROL_INFO } 

The objective of the SM_MAC„ACTION__VALUE . INVOKE command by 
the SM is to force a MAC operation in the MAC as defined by 
the parameter_ID structure. This structure specifies the 
action to be performed. 


SM_MAC„ACTION_VALUE . REPLY 
{ STATUS, ACTION JREPORT }j 


The objective of the reply by the MAC to the 
indicate the success or failure of 
SM MAC_ACTION_VALUE . INVOKE . The SM expects 
overwrite the SM_MAC_ACTION_VALUE . INVOKE 
SM_MAC_ACTION_VALUE . REPLY thus allowing the SM 
the message buffer. 


SM is to 
a previous 
the MAC to 
with the 
to release 


MAC_SM_EVENT_VALUE . NOTIFY 
{ EVENT_ID } 


The objective of the MAC_SM„EVENT_VALUE . NOTIFY command by 
the MAC is to report a event which has occurred m the MAO 
as defined by the EVENT_ID structure. This structure 
specifies the Event and an integer. These events can be 
masked by setting the EVENT_MASK variable. 



Mil I CD Program 
ARCHITECTURE 


Page 30 
21 July 1987 


MAC_SM_EVENT„VALUE . REPLY 
{ STATUS } 

The objective of the following reply by the SM to the MAC is 
to indicate the success or failure of a previous 
MAC SM„EVENT_VALUE . NOTIFY . The MAC expects the SM to 
overwrite the MAC_SM_EVENT_VALUE . NOTIFY with the 
MAC_SM_EVENT_VALUE . REPLY thus allowing the MAC to release 
the message buffer. 
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3.11.2.1.1 IEEE 802.3 SM MANAGEMENT - 

See the IEEE 802 specifications for actual meanings. Some 
parameters have additional explanations. Specific 
implementations may have differences and the Station Manager 
must be able to resolve them. This set is taken from the 
IEEE 802 document and some implementations may not provide 
all the variables, however in such a case implementations 
will respond with a proper status (non-compliance or error, 
etc). 

Additions may be made so -as to support future changes 
providing that only new additions are made. Tags found in 
this standard may not be modified. New ones may be created 
and added as optional parameters. 


ORIGINAL- PAGE IS 

op poor quality: 
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READ_WRITE_VALUE_TYPES ::= CHOICE 


\ [0] 


Mac_type 



1 

M] 


Memory 



1 

[2] 


S 1 ot_t ime 



1 

[3] 


I n t e r_f rame_gap 



1 

[4] 


At t emp t_ limit 



1 

[5] 


Back_of f _ 1 i m i t 



1 

[6] 


Jam_s i ze 



1 

[7] 


Max_f rame_s i ze 



1 

[8] 


M i n_f rame_s i ze 



1 

[9] 


Add ress_s i ze 



1 

[10] 


Event_enab 1 e_mask 



1 

[11] 


Ma_g roup_add r ess 



1 

[12] 

\ 


Ts 




Memory 

. _ 

SEQUENCE 




[ ici_mem_l 

ink [0] Mem_block, — list 

of 

f ree 

ICI blocks 

pdu_mem_ 1 

1 

ink [1] Mem_block — list 

of 

f ree 

PDU blocks 

Mem_block 

:= SEQUENCE 




| block. 

.size INTEGER, — size of each 

block 


block, 

\ 

-Pt r 

Address — pointer to 

first word in block 

Ts : : = 

Va 1 ue_add ress_1 




This variable represents the address 

of 

this 

stat ion. 

S 1 ot_t i me : 

:= Va 1 ue_i nteger_1 





This variable represents the slot time of this station. Thi 
is the maximum time this station must wait on another 
station to respond to a transmission. 

Event_enab I e_mask : := Event_enab I e_b i t s 

Even t_enab I e_b i t s : := BIT STRING 
{ I ow_ i c i _mem (0) , 

low_pdu_mem ( 1 ) , 

dup I i ca t e_add ress (2), 

f au I t y t ransm i t ter (3), 

xmi t_queue_threshol d_exc ceded (4) , 

r ece i ve_queue_t h res ho I d_exceeded (5) , 
watch_dog_t imeout (6). 

max_re t ry_encoun t e r ed (7), 
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bad_message_sen t 


I 


( 8 ), 

— Where 1 is enabled 


The MAC will report events when discovered and the 
appropriate bit is set in the MASK above. The event is 
reported only once whenever the actual occurrence is 
detected . 
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A 1 1 empt_ I i m i t : :== Va I ue_ i ntege r_1 

Ma_group_add ress : := SEQUENCE 
) add ress_no INTEGER, 

group_add Va I ue_add ress_1 

\ 

The MAC can respond to a list of group addresses. This is 
the method for the Station Manager to tell the MAC which 
addresses are acceptable. The collection of valid group 
addresses can be thought of as an array where ADDRESS_NO is 
the index into the array and the GROUP_ADD is the actual 
address. This command will set this address as part of the 
group addresses (unless there all used up). Different 
implementations may limit the size of the array. 

Mac_type : := 03h 

This variable is a read only variable and indicates which 
version of MAC is responding. 

I n t e r_f rame_gap : Va I ue_i nteger_1 

Back_of f_ I i m i t ::= Va I ue_ i n t ege r_1 

Jam_size : := Va I ue_ i nteger_1 

Max_f rame_s i ze ::= Va I ue_i ntege r_1 

Mi n_f rame_s i ze ::= Va I ue_i nteger_1 

Address_size : := Va I ue_ i nt ege r_1 

Status_type ::= CHOICE 


undef i ned_error 

[0] 

Va 1 ue_i nteger_1 

success 

[1] 

Va 1 ue_ i ntege r_1 

ref use_to_compl y 

[2] 

Va 1 ue_i nteger_1 

not_suppor ted 

[3] 

Va 1 ue_ i ntege r_1 

error_i n_perf or 

[4] 

Va 1 ue_i nteger_1 

not_avo i 1 ab 1 e 

[5] 

Va 1 ue_i nteger_1 

bad_paramete r_ i d 

[6] 

Va 1 ue_ i ntege r_1 

bad_parameter_operat i on 

[7] 

Vo 1 ue_ i ntege r_1 

bad_pa ramete r_va 1 ue 

[8] 

Va 1 ue_i nteger_1 

bad_expec ted_va 1 ue 

[9] 

Va 1 ue_i nteger_1 
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These are responses to a command indicating the status of 
the command. Following are expected uses of these responses; 


unde f i ned_e r ro r — Request was not understood or no 

appropriate error message avai lable. 
success - A successful operation has been completed, 
r e f use_t o_c omp I y — The operation was impossible or illegal, 
nonsupported - The operation is not supported or 
recogn i zed . 

er ror_ i n.pe r f or - A error was encountered 
during ope rat ion. 

not_ava i I ab I e — Information is not yet 
avai lable. 

bad_parameter_i d — Parameter ID was not 
recogn i zed . 

bad_parameter_operat ion - Operation requested 

was not recognized 
bad_pa rame t e r_va I ue — The Parameter 

value was bad. 

bad.e x pec t ed_va I ue — The expected value was 

i I I ega I . 

Event.types : IMPLICIT SEQUENCE 
I event_c lass Event_c I ass_types j 

Event.c I ass.types : := CHOICE 

I local [ 0 ] Event_ i dent i f i er_types j 

remote [l] Event_i dent i f ier_types } 

Events in this implementation are always LOCAL (as opposed 
to events that occurred in a remote node). 


Event_ i dent i f i er_types : CHOICE 
| I ow_ i c i _mem 
I ow.pdu.mem 
dupl icate_address 
f au I ty_t ransmi t ter 
xm i t_queue_t h resho I d_exceeded 
rece i ve_queue_t h resho I d_exceede< 
watch_dog„t imeout 
max_ r e t ry_encoun t e red 
bod_message_sen t 


[0] 

Va 1 ue.address.l 

[1] 

Va 1 ue_address_1 

[2] 

VALUE_INTEGER_1 

[3] 

VALUE. INTEGERS 

[4] 

VALUE_INTEGER_1 

[5] 

VA LU E_ I NT EG ER__ 1 

[6] 

VALUE_INTEGER_1 

[7] 

VALUE_INTEGER_1 

[8] 

Va 1 ue_address_1 
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These events are-reported upon the discovery of the 
following conditions; 

I ow_ i c i _mem - Flagged when the MAC detects it has or 
is running out of ICI memory blocks. 

I ow_pdu_mem - Flagged when the MAC detects it has or 
is running out of PCI memory blocks. 

dup I i cat e_add ress — 

f au i t y_t ransm i t t e r — 

xm i t_queue_threshold_exceeded - 

rece i ve_queue_t hresho I d_exceeded - Flagged when the MAC 

cannot get buffer 
space for i ncom i ng 
data . 

watch_dog_t imeout — Flagged if the hardware watch dog 
timer expires. 

max_ret ry_encount e red - Flagged when a the max retry is 

encountered . 

bad_message_sen t -Flagged when the MAC discovers a message 
which does not agrees with its indicated 
structure size (i.e. bad length field). 


Act i on_va I ue_types : := CHOICE 


| reset 

[ 0 ] 

Va 1 ue_ i nt ege r_1 } 

OPERAT ION_COMMAND_TYPES :: 

= CHOICE 

\ test_« 

[03 

R E AD_WR I T E_V A L UE_T YP ES 

A 

A 

W 

*> 

[13 

Read_wr i te_va 1 ue_types 

test _=* 

[ 2 ] 

Read_wr i te_va 1 ue_ types 

A 

V 

l 

V) 

*> 

[ 3 ] 

Read_wr i t e_va 1 ue_t ypes 

t est_<= 

[4] 

Read_wr i te_va 1 ue_ types 

test_>= 

[5] 

Read_wr i te_va 1 ue_ types 

«_g i ven_constant 

[ 6 ] 

G i ven 

»_g i ven_constant 

[ 7 ] 

G i ven 

— _g i ven_constant 

[ 8 ] 

Given 

<>_g i ven_const ant 

[ 9 ] 

G i ven 

<=_g i ven_constant 

[ 10 ] 

G i ven 

>=_g i ven_constant 

[11] G i ven 

The above operations 

expects a variable (we’ll cal 


be internal The complete structure includes either a 
variable or constant which we’ I I cal I var2. The constant is 
used to overwrite Vart in case the operation test true so in 
the case of two internal vars being tested a constant is 



MI I ICD Program 
ARCHITECTURE 


Page 37 
21 July 1987 


also passed in. .The above operation commands imply the 
f o I lowing: 
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test_« - i 

f vofI 

« 

va r2 

then 

var1=constant 

test_» - i 

f varl 

» 

va r2 

then 

var1=constant 

test _= - i 

f varl 

= 

va r2 

then 

var 1=constant 

l 

A 

V 

l 

V) 

V 

f varl 

<> 

va r2 

then 

var1=constant 

test__<= - i 

o 

> 

<= 

va r2 

then 

var 1=cons t an t 

test_>= - i 

f varl 


va r2 

then 

var 1=const ant 


«_g i ven_const ant - if varl « constant then var1=constant 

»_g i ven_constant — if varl » constant then var1=constant 

— _g i ven_const ant — if varl = constant then va r1=constant 

<>_g i ven_constant — if varl <> constant then va r 1=const an t 

<=_g i ven_constant - if varl <= constant then va r1=constant 

>=_g i ven_constant - if varl <= constant then var 1=constont 

Varl is a MAC parameter to be tested (internal). Its value 
is always returned along with a status. Var2 is a MAC 
parameter (internal) or a constant (external) used in the 
comparison of Varl (internal). Varl always refers to a 
variable located in the MAC. Var2 is either located in the 
MAC (a compare of two internal variables) or as a constant 
(external) passed in. In all cases a true test forces Varl 
to be a external constant. 

Constant : := Va I ue_ i n t ege r_1 

Va I ue_ i n t ege r_1 ::= IMPLICIT Long_word 

Va I ue_add ress_1 : IMPLICIT Long_word (32 8ITS) 

Va I ue_address_1 6 : := IMPLICIT ARRAY OF 16 Long_words 

(32 BITS EACH) 
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3.11.2.1.1.1 SYNTAX - 

STATION MANAGER INTERFACE SYNTAX 

The station manager communicates to the MAC across the Mil. 
The syntax of such communication is described below 
according to Abstract Syntax Notation One or ASN.l (ISO DIS 
8824). The information described is encoded to the basic 
coding rules as found in ASN.l (ISO DIS 8825). Some sample 
records follow the syntax notations. 



0 >:iGBTiVO PASS IS. 
•3 POOR QUAL TTY! 
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3.11.2.1.1.2 -FORMAL SYNTAX SPECIFICATION - 


Message_r eco r d [PRIVATE 0] CHOICE 

| [0] Sm_mac_ I m_se t_va I ue . i nvoke 

[1] Sm_mac_ I m_se t_va I ue . rep I y 

[2] Sm_mac_ lm_get_va I ue . invoke 

[3] Sm _mac_ I m_ge t_va I ue . reply 

[4] Sm_mac_ I m_compa re_ond_se t_va I ue . invoke 

[5] Sm_mac_ lm_compare_and_set_va I ue . rep I y 

[6] Sm_mac_ac t i on_va I ue . i nvoke 

[7] Sm _mac_ac t i on_va I ue . rep I y 

[8] Sm_mac_event_va I ue . not i f y 

[9] Sm_mac_event_va I ue . rep I y 


Sm_mac_lm_set_val ue . i nvoke : := IMPLICIT SEQUENCE 
| pa r ame t e r_ t ype Read_wr i te_va I ue_types , 

access_con t ro I _ i nf o NULL J 

Sm_moc_ lm_se t_va I ue , rep I y : IMPLICIT SEQUENCE 
{ Return_val Read_wr i te_va I ue_types , 

status Status_typej 

Sm_mac_ I m_ge t_va I ue . invoke : := IMPLICIT SEQUENCE 
I Pa ramet e r_t ype Read_wr i te_va I ue_types 

access_cont ro I _ i nf o NULL } 

Sm_mac_lm_get_va I ue . reply : := IMPLICIT SEQUENCE 
| Parameter_type Read_wr i te_va I ue_types , 
status Status_type [ 

Sm_mac_lm_compare_and_set_value. i nvoke ::= IMPLICIT SEQUENCE 
{ parameter_type Dummy_rw_t ypes , 

operat i on_command Operat i on_command_t y pes , 

occess_cont rol_info NULL } 

Sm_mac_ I m_compa r e_and_se t_va I ue . reply : := IMPLICIT SEQUENCE 
} return_val Read_wr i te_va I ue_types , 

status Status_type [ 

Sm_mac_act i on_va I ue . i nvoke : := IMPLICIT SEQUENCE 
\ parameter_id Act i on_va I ue_types , 

access_cont rol_info NULLj 

Sm_mac_oc t i on_va I ue . rep I y : := IMPLICIT SEQUENCE 
{ status Status_type, 

act i on_report NULL [ 
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Mac_sm_event_val ue. not i fy : := IMPLICIT SEQUENCE 
$ Event_id £vent_types | 

Mac_sm_event_va I ue . rep I y : := IMPLICIT SEQUENCE 
\ Status Stat us_type \ 

Read_wr i te_va I ue_types : CHOICE 
I [0] Mac_type 

[ 1 ] Memory 

[2] S I ot_t ime 

[3] Inte r_f rame_gap 

[4] At tempt_l imi t 

[5] Back_of f_l Imi t 

[ 6 ] J am_ .s i ze 

[ 7 ] Max _ f r ame_s i ze 

[8] M i n_f rame_s i ze 

[9] Address_size 

[10] Event_enab I e_mask 

[11] Ma _g roup_add ress 

[12] Ts 

i 

Dummy_ rw_t y pes : := CHOICE 
mac_type 
s I ot_t i me 
i nter_f rame_gap 
at tempt_l imi t 
bock_of f_l imi t 
j am_s i ze 
max_f rame_s i ze 
m i n_f r ame_s i ze 
add ress_s i ze 
event_enabl e_mask 
ma_g roup_add ress 
t s 
\ 

Memory : := SEQUENCE 
[ i c i_mem_l i nk [0] Mem_block, — list of free ICI blocks 

pdu_mem_link [1] Mem_block — list of free PDU blocks 

* 

Mem_b I ock : := SEQUENCE 

[ block_size INTEGER, — size of each block 

b I ock_pt r Address — pointer to first word in block 

\ 


[0] Va I ue_ i n t ege r_1 

[2] Va I ue_ i nt ege r_1 

[3] Va I ue_i nteger_1 

[4] Va I ue_ i nteger_1 

[5] Valye_integer_1 

[6] Va I ue_ i nteger_1 

[7] Value_integer_1 

[8] Va I ue_i nteger_1 

[9] Va I ue_ i ntege r_1 

[10] Va I ue_ i nteger_1 

[11] Va I ue_i nteger_1 

[12] Vo I ue_add ress_1 
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Ts : := Va I ue_add ress_l 

Ns : := Va I ue_add ress_1 

Slot_time ::= Va I ue_ i nteger_1 

Event _e nab I e_mask : := EVENT_ENABLE_BITS 

Ma_group_address : := SEQUENCE 
\ Address_no INTEGER, 

Group_add Va I ue_add ress_1 

i 


Mac_type : := 03h 
Status_type ::= CHOICE 


undef i ned_er ror 

[0] 

Va 1 ue_ 

i nteger_ 

success 

[1] 

Va 1 ue_ 

i nt ege r_ 

ref use_t o_comp 1 y 

[2] 

Va 1 ue_ 

i nt ege r_ 

not_supported 

[3] 

Va 1 ue_ 

i nteger_ 

error_i n_pref or 

[4] 

Va 1 ue_ 

i nteger_ 

not_ava i 1 ab 1 e 

[5] 

Va 1 ue_ 

i ntege r_ 

bad_pa rameter_ i d 

[6] 

Vo 1 ue_ 

i ntege r_ 

bad_parameter_operat ion 

[7] 

Va 1 ue_ 

i nteger_ 

bad_pa ramet e r_va 1 ue 

[8] 

Va 1 ue_ 

i nt ege r_ 

bad_expec ted_va 1 ue 

[9] 

Va 1 ue_ 

i nt ege r_ 


Event_types : := IMPLICIT SEQUENCE 
$ event_class Event_c I ass_types $ 

Event_c I ass_types : CHOICE 

[ local [0] Event_ i den t i f i e r_t ypes | 

remote [1] Event_ident i f ier_types $ 


Event_i dent i f i er_types : CHOICE 


i 

1 ow_ i c i _mem 

[0] 

Va 1 ue_i ntege r_1 


1 ow_pdu_mem 

[0 

Va 1 ue_ i ntege r_1 


dupl i cate_address 

[2] 

Vo 1 ue_ i nteger_1 


f au 1 ty_t ransmi t ter 

[3] 

Va 1 ue_i nteger_1 


xmi t_queue_t hreshol d_exceeded 

(4] 

Va 1 ue_ i ntege r_1 


rece i ve_queue_threshold_exceeded 

[5] 

Va 1 ue_i nteger_1 


watch_dog_t imeout 

[6] 

Va 1 ue_ i ntege r_1 


max_ret ry_encountered 

[7] 

Va 1 ue_ i ntege r_1 


bad_message_sen t 

[8] 

Va 1 ue_add ress_1 

Event _e nab 1 e_b i t s ::= BIT STRING 



\ 

1 ow_i c i_mem 

O). 



1 ow_pdu_mem 

0). 



dupl i cate_address 

(2). 



faul ty_transmi tter 

(3), 



I 
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xmi t_queue_threshol d_exceeded ( 4) , 

rece i ve_queue_t h resho I d_exceeded (5) , 
watch_dog_t i meout (6), 

max_ret ry_encountered (7), 

bad_message_sent (8) [ — 


is enabled 


Ac t i on__va I ue_t ypes ::= CHOICE 


\ reset 

[0] 

Va l ue_i nteger_ 

Ope rat i on_command_t ypes :: 

= CHOICE 

} test_« 

[0] 

Dummy_rw_ types 

test_» 

[1] 

Dummy_rw_ types 

test 

[2] 

Dummy_rw_ types 

test_<> 

[3] 

Dummy_rw_ types 

t est_<= 

[4] 

Dummy_rw_t ypes 

test _>= 

[5] 

Dummy _ rw_t y pes 

«_g i ven_cons t ant 

[6] 

Given 

»_g i ven_cons t an t 

[7] 

Given 

=_g i ven_cons t an t 

[8] 

Given 

<>_g i ven_constant 

[9] 

G i ven 

<=_g i ven_constant 

[10] 

Given 

>=_g i ven_constant 

[11] 

G i ven 

Given : := CHOICE 

j [0] Va 1 ue_ i n t ege r 

_1 

I 

[l] Va 1 ue_add ress 

_1 

i 

Constant : := Value_i 

ntege 

r_1 


I 


I 


Va I ue_ i n t ege r_1 : := IMPLICIT INTEGER 

Value_address_1 : IMPLICIT Long_word (32 BITS) 

Va I ue_odd ress_1 6 : IMPLICIT ARRAY OF 16 Long_words 

(32 BITS EACH) 
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3.11.2.1.2 IEEE 802.4 SM MANAGEMENT - 

See the IEEE 802 specifications for actual meanings. Some 
parameters have additional explanations. Specific 
implementations may have differences and the Station Manager 
must be able to resolve them. This set is the is taken from 
the IEEE 802 document and some implementations may not 
provide a variable, however in such a case all 
implementations will respond with a status (non-compliance 
or error , etc ) . 

Additions may be made so as to support future changes 
providing that only new additions are made. Tags found in 
this standard may not be modified. New ones may be created 
and added as optional parameters. 
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Read^wr i t e_ 

va 1 ue_types CHOICE j 

[0] 

Mac_type ' 

[1] 

Memory ! 

[2] 

Slot time ! 

| 

[3] 

Hi_pr i_token_hold_t ime 

[4] 

Max_ac_4_rotat ion_t ime 

[5] 

Max_ac_2_rotat i on_t ime 

[6] 

Max_ac_0_rotat i on_t i me 

[7] 

Mac r i ng_ma i ntenance_rotat i on_t ime 

[8] 

R i ng_ma i ntenance_t i me r_ i n i t i a 1 _va 1 ue 

[9] 

Max_i nter_so 1 ici t_count 

[10] 

Mi n_post_si 1 ence_p reamb 1 e_l ength 

[Hi 

Event_enab 1 e_mask 

[12] 

Max_ret ry_ 1 im i t 

[13] 

Ma_group_add ress 

[15] 

Channe l_assi gnments 

[16] 

Transmi 1 1 ed.powe r _ 1 eve 1 _ad j us tment 

[17] 

Transmi t ted_output_i nh i bi ts 

[18] 

Rece i ved_s i gna 1 _sou rces 

[19] 

Signal i ng_mode 

[20] 

Rece i ved_s i gna l_l eve l_ report i ng 

[21] 

Lan.topol ogy.type 

[22] 

Ts 

[23] 

Ns 


\ 


Memory : SEQUENCE 
| ici_mem_link [0] Mem_block, 
pdu_mem_link [1] Mem_block 


I j st of f ree ICI blocks 
list of f ree PDU blocks 


\ 


Mem_b I ock : := SEQUENCE 

\ block.size INTEGER, — size of each block 

block.ptr Address -pointer tofirst word tn block 

\ 


j s ; ; = Va l ue_address_1 

This variable represents the address of this station, 

Ns : := Va t ue_address_1 

This variable represents the address of the next station 

Slot t i me : Val ue_i nteger.l 

H i _pr i _t oken_ho I d_t i me : := Va I ue_ i nt ege r_1 

Max_ac_4_rotat i on_t ime : := 


Va I ue_ i ntege r_1 
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Mox_ac_2_rot at i on_t ime : := Va I ue_ i nt ege r_1 
Max_ac_0_rotat ion.t ime : := Va I ue_ i n t ege r_1 

Mac_ring_maintenance„rotation_time : Val ue_i nteger_1 
R i ng.ma i ntenance.t imer.i ni t i a l_vo I ue • ■- Va I ue_i nteger_ 

Max.inter.sol ici t.count : Vo I ue_ i n t ege r_1 
M i n.pos t_s i I ence_preamb I e_ I engt h : := Va I ue_i nteger_1 
In_ring : Va I ue_i nteger_1 
Max_retry_l imit : Va I ue_i ntege r_1 

This is the maximum number of times that a packet will 
retransmitted when the acknowledgement indicates a bad 
t ransm i ss i on . If this is a connec t i on- 1 ess system th.s 
variable should not be used. 

Ma.group.address : SEQUENCE 

\ oddress_no INTEGER, 

group_add Va I ue_add ress_1 \ 

The MAC can respond to a list of group addresses This is 
the method for the Station Manager to tell the MAC wh , c 
addresses are acceptable. The collection of valid group 
addresses can be thought of as an array where ADDRESS.NO 
the index into the array and the GROUP.ADD is the actua 
address. This command will set this address as part of the 
group addresses (unless there all used up). Different 
implementations may limit the size of the array. 

Channe I _ass i gnment s : := Va I ue_ i ntege r_1 

T ransm i 1 1 ed_powe r_ I eve l_ad j ustment : Va I ue__i ntege r_1 

T ransm i 1 t ed.output.i nh i b i t s : Val ue_i nteger.l 

Rece i ved__s i gna I .sources : := Va I ue_ i nteger.l 

Signal i ng^mode : := Va I ue_ i nteger_1 

Rece i ved_s ignal_level_re porting : Va I ue_ i nteger.l 
Lan.topo I ogy.ty pe : Va I ue_ i ntege r„1 
Mac.type : := 04h 
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This variable is a read only variable 
version of MAC is responding. 

STATUS_TYPE : := CHOICE 


unde f i ned_e r r o r [0] 
success [1] 
r e f use_t o_comp I y [2] 
nonsupported [3] 
er ror_i n_perf or [4] 
not_ava i I ab I e [3] 
bad_parameter_.i d [6] 


bad_parameter_operat i on [7] 
bad_parameter_va I ue [8] 
bad_expected_va I ue [9] 

These are responses to a command i nd 
the command. Following are expected 


and indicates which 


Va I ue_ i nt ege r_1 | 

Va I ue_i nteger_1 | 

Va I ue_i nt ege r_1 | 

Va I ue_i ntege r_1 I 
Va I ue_i ntege r_1 | 

Va I ue_i nteger_1 | 

Va I ue_i nteger_1 | 

Va I ue_ i nt ege r_1 | 

Va I ue_i ntege r_1 | 

Va I ue_i ntege r_1 ( 

i cat i ng the status of 
uses of these responses 


unde f i ned_e r ro r - Request was not understood or no 

appropriate error message available, 
success - A successful operation has been completed, 
ref use_to_comp I y - The operation was impossible or illegal 
not_supported - The operation is not supported or 
recogn i zed . 

error_in_perfor - A error was encountered 
during ope rat ion. 

not_avai lable - Information is not yet 
ava i lable. 

bad_pa ramet e r_ i d - Parameter ID was not 
recogn i zed . 

bad_parameter_operat i on - Operation requested 

was not recognized 
bad_parometer_va I ue - The Parameter 

value was bod. 

bad_expected_va I ue - The expected value was 

i I I ega I . 

event_enobl e_mask : EVENT_ENABLE_BITS 


Ewent_enabl e_bi ts : BIT STRING 

| I ow_ i c i _mem 
I ow_pdu_mem 
dupl i cate_address 
f aul ty_transmi tter 

xmi t_queue_threshold_exceeded 
recei ve_queue_threshol d_exceeded 
watch_dog_t imeout 
token_l ost 
dua I _t oken 

max_ret ry_encountered 
bad_message_sent 


( 0 ). 

(D. 

( 2 ), 

(3) . 

(4) . 

(5) , 

( 6 ) , 
( 8 ), 

(9) . 

( 10 ) 
( 11 ) 
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ns_changed - (12), 

ns - nul1 (13), } — 1 is enabled 

The MAC will report events when discovered and the 
appropriate bit is set in the MASK above. Bit 0 is the 
NS— Station, bit 1 is the NS_NULL etc. These bits are 
inspected each time the event has occurred and the MAC 
is active. The event is reported only once whenever the 
actual occurrence is detected. 


Event_types : : = IMPLICIT SEQUENCE 
J event_class Event_c I ass_types 


Event_c I ass_types : CHOICE 
I local [0] Even t_ i den t i f i e r_ types 

remote [1] Event_i dent i f i er_types 


I 


Events in the Mil implementation are always LOCAL (as 
opposed 

to events that occurred in a remote node). 


Event_ i dent i f i e r_types CHOICE 


| Low_ici_mem 

[ 0 ] 

Vo 1 ue_ i nteger_1 

Low_pdu_mem 

[1] 

Va 1 ue_ i n t ege r_1 

Dupl i co t e_add ress 

[2] 

Va 1 ue_ i n t ege r_1 

Faul ty_transmi tter 

[3] 

Vo! ue_i nteger_1 

Xm i t_queue_t h res ho 1 d_exceeded 

[4] 

Va 1 ue_i nteger_1 

Rece i ve_queue_t h resho 1 d_exceeded 

[5] 

Va 1 ue_ i nt ege r_1 

Watch_dog_t imeout 

[6] 

Va 1 ue_ i nteger_1 

Token_l ost 

[ 8 ] 

Va 1 ue_ i n t ege r_1 

Duo l_token 

[ 9 ] 

Val ue_i nteger_1 

Max_ret ry_encountered 

[10) 

Va 1 ue_ i nteger_1 

Bad_message_sen t 

[113 

Va 1 ue_add ress_1 

Ns_nu 1 1 

[ 12 ] 

Va 1 ue_ i nt ege r_1 

Ns_changed 

[13) 

Val ue_i nteger_1 


\ 


These events are reported upon the discovery of the 
following conditions; 


low_ici_mem - Flagged when the MAC detects it has or 
is running out of I C I memory blocks. 


I ow_pdu_mem - Flagged when the MAC detects it has or 
is running out of PCI memory blocks. 


ns__changed - Flagged when the event routine discovers a 
change in the NS 

address . 


ns_nu I I - Flagged when the NS is set to NULL 
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dup I i ca t e_add ress - reports duplicate addresses other 
addresses . 

f au I ty_t ransm i t ter - Reports faulty transmitter. 

xm i t_queue_t h resho I d_exceeded - Flagged when the MAC 

cannot get buffer space 
for outgoing data. 

rece i ve_queue_t h resho I d_exceeded - Flagged when the MAC 

cannot get buffer 
space for incoming 
data . 

wa t ch_dog_ t i meou t — Flagged if the hardware watch dog 
timer expires. 

token_lost - Flagged when the token is detected as 
lost. 

dual_token - Flagged when a extra token is discovered. 

max_ret ry_encounte red - Flagged when a the max retry is 

encountered . 

bad_message_sen t -Flagged when the MAC discovers a message 
which does not agrees with its indicated 
structure size (i.e. bad length field). 

Act i on_va I ue_types : CHOICE 

| reset [0] Va I ue_i nteger_1 } 

The ACT ION_VALUE_TYPES allow the following; 

Reset Va I ue_i ntege r_1 * anything: 

A reset will flush all queues, set all operating parameters 
to their initial values, lose the token (if its holding it), 
and await work from either the media or the LLC. 

OPERAT ION_COMMAND_TYPES : := CHOICE 


| test_« 

[03 

Read_wr i te_va 1 ue_types 

A 

A 

1 

V) 

V 

[1] 

Read_wr i te_va 1 ue_types 

test_= 

[23 

Read_wr i te_va 1 ue_types 

A 

V 

l 

in 

V 

[3] 

Read_wr i t e_vo 1 ue_ types 

test _<= 

[4] 

Read_wr i t e_va 1 ue_t y pes 

test _>= 

[5] 

Read_wr i te_va 1 ue_types 

«_9 * ven_constant 

[6] 

Given 

»_g i ven_constant 

[7] 

Given 

=_g i ven_constant 

[8] 

G i ven 
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<>_g i ven_constant [9] Given | 

<=_g i ven_cons tant [10] Given | 

>=_g i ven_constant [11] Given i 

The above operations expects a variable (we'll call varl) to 
be internal. The complete structure includes either a 
variable or constant which we’ll call var2. The constant is 
used to overwrite Varl in case the operation test true so in 
the case of two internal vars being tested a constant is 
also passed in. The above operation commands imply the 
f o I lowing: 

test_« - if varl « var2 then var 1=constant 

test_» - if varl » var2 then var1=const ant 

test _= - i f varl = var2 then var 1=constant 

test_<> - if varl <> var2 then var1=constant 

test_<= - if varl <= var2 then var 1=constant 

test_>= - if varl >= var2 then var Inconstant 

«_g i ven„constant - if varl « constant then va r Inconstant 

»_g i ven_constant - if varl » constant then var1=constant 

=_g i ven_constant - if varl = constant then var1=constant 

<>_g i ven_constant - if varl <> constant then varl^constant 

<=_g i ven_constant - if varl <= constant then var1=constant 

> = _9 i ven_ constant - if varl <= constant then va r 1=cons t an t 

Varl is a MAC parameter to be tested (internal). Its value 
is always returned along with a status. Var2 is a MAC 
parameter (internal) or a constant (external) used in the 
comparison of Varl (internal). Varl always refers to a 
variable located in the MAC. Vor2 is either located in the 
MAC (a compare of two internal variables) or as a constant 
(external) passed in. In all cases a true test forces Varl 
to be a external constant. 

Constant : := Va I ue_i ntege r_1 

Va I ue_i nteger_1 : := IMPLICIT long_word 

Va I ue_add ress_1 : IMPLICIT Long_word (32 BITS) 

Va I ue_add ress_1 6 : :* IMPLICIT ARRAY OF 16 Long_words 

(32 BITS EACH) 
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3.11.2.1.2.1 SYNTAX - 

STATION MANAGER INTERFACE SYNTAX 

The station manager communicates to the MAC across the Mil. 
The syntax of such communication is described below 
according to Abstract Syntax Notation One or ASN.l (ISO DIS 
8824). The information described is encoded to the basic 
coding rules as found in ASN.l (ISO DIS 8825). Some sample 
records follow the syntax notations. 
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3.11.2.1.2.2 -FORMAL SYNTAX SPECIFICATION - 


Me ssoge_ record : :* [PRIVATE 0] CHOICE 

I [0] Sm_mac_ lm_set_va I ue . i nvoke I 

[1] Sm_mac_ I m_se t_va I ue . rep I y j 

[2] Sm_mac_lm_get_va I ue . i nvoke J 

[3] Sm_mac_ I m_ge t_va I ue . rep I y j 

[4] Sm_mac_ lm_compa re_and_set_va I ue . i nvoke I 

[5] Sm_mac_ I m_compa re_and_set_va I ue . rep I y I 

[6] Sm_mac_ac t i on_va I ue . i nvoke I 

[7] Sm_mac_ac t i on_va I ue . rep I y I 

[8] Sm_mac_event_va I ue . not i f y | 

[9] Sm_mac_event_va I ue . rep I y j 

Sm_mac_ I m_set_va I ue . invoke : := IMPLICIT SEQUENCE 
{ pa rome t e r_ t y pe Read_wr i te_va I ue_types 

access_cont ro I _ i nf o NULL [ 

Sm_mac_ I m_se t_va I ue . reply : IMPLICIT SEQUENCE 
[ return_val Read_wr i t e_va I ue_ty pes , 

status Status_type} 

Sm_mac_lm_get_va I ue . i nvoke : := IMPLICIT SEQUENCE 
[ parameter_type Read_wr i te_va I ue_t ypes 

access_cont rol_i nf o NULL j 

Sm_mac_ tm_get_value. reply : IMPLICIT SEQUENCE 
[ pa rame t e r__t ype Read_wr i te_vot ue_types 
status Status_type j 

Sm_mac_ lm_compare_and_set_val ue. invoke : :* IMPLICIT SEQUENCE 
j pa r ame t e r_ t ype Dummy_rw_ types , 

ope rat i on_command Ope rati on_command_ types , 

access_cont rol_i nf o NULL } 

Sm_mac_ I m_compa re_and_.se t_va I ue . rep I y : IMPLICIT SEQUENCE 

[ return_val Read_wr i te_va I ue_types , 

status Status_type } 

Sm_mac_act i on_va I ue . i nvoke : := IMPLICIT SEQUENCE 
} po ramet e r_ i d Act i on_va I ue_types , 

access_cont ro I _ i nf o NULL} 

Sm_mac_act i on_va I ue . rep I y : := IMPLICIT SEQUENCE 
} status Stotus_type, 

ac t i on_repor t NULL } 
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} event_id - Event_types [ 

Mac_sm_event_va I ue . rep I y : := IMPLICIT SEQUENCE 
{ status Status_type ] 

Read_wr i te_va I ue_types ::= CHOICE { 


[0] 

Mac_ type 

[1] 

Memory 

[2] 

S 1 ot_t ime 

[3] 

Hi_pr i_token_ho 1 d_t ime 

[4] 

Max_ac_4_rotat i on_t ime 

[5] 

Max_ac_2„rotat ion_t ime 

[6] 

Max_ac_0_rotat ion_t ime 

[7] 

Mac_r i ng_mo intenance_rotat i on_t i me 

[8] 

R i ng_ma i n t enance_t i me r_ i n i t i a 1 _va 1 ue 

[9] 

Max_ i nter_sol ic i t_count 

[10] 

M i n_pos t_s i 1 ence_preamb 1 e_ 1 engt h 

[11] 

Event_enabl e_mask 

[12] 

Max_ re t ry_ limit 

[13] 

Ma_g roup_add ress 

[15] 

Channe l_ass i gnments 

[16] 

Transmi 1 1 ed_powe r_ 1 eve 1 _ad j us tmen t 

[17] 

Transmi t ted_output_i nh i bi ts 

[18] 

Receive d_sig no l_sources 

[19] 

S i gna 1 i ng_mode 

[20] 

Rece i ved_s ignal_level_report ing 

[21] 

Lan_topo 1 ogy_type 

[22] 

Ts 

[23] 

Ns 

Memory 

:= SEQUENCE 


I i c i _mem_ link [0} Mem_block, — list of free ICI blocks 
pdu_mem_link [1] Mem_block — list of free PDU blocks ] 


Mem_b I oc k : := SEQUENCE 

I block_size INTEGER, — size of each block 

b I ock_pt r Address — pointer to first word in block ] 


Dummy_rw_types : CHOICE J 

mac_type 

ns 

s I ot_t ime 

hi_pr i_token_hold_t ime 
max_ac_4_rotat i on_t i me 
max_ac_2_rotat i on_t ime 
max_ac_0_rotat ion_t ime 
mac_r i ng_mo intenance_rotat ion_t ime 
r i ng_ma i n t enance_t ime r_ i n i t i a I _va I ue 
max_ i nte r_so I i c i t_count 
m i n_post_s i I ence_preamb I e_l engt h 


[0] Va I ue_ i nt ege r_1 

[1] Va I ue_ i nteger_1 

[2] Va I ue_ i nt ege r_1 

[3] Va I ue_i nteger_1 

[4] Va I ue_ i nt ege r_1 

[5] Vaf ue_i nteger_1 

[6] Va I ue_ i nt ege r_1 

[7] Va I ue_i nteger_1 

[8] Va I ue_ i n t ege r_1 

[9] Va I ue_ i nteger_1 

[10] Va I ue_ i n t ege r_1 
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event_enabl e_mas-k 

max_ret ry__ limit 

ma_g roup_add ress 

channel _assi gnmen t s 

t ransm i 1 1 ed_powe r_level_adj us t men t 

t r ansm i 1 1 ed_ou t put i n h i b i ts 

receive d_signal_sources 
s i gna I i ng_mode 

received_signal__level_report ing 
I an_t opo I ogy_t ype 
t s 


[ 1 1 ] Va I ue_ i n t ege r_1 | 

[12] Va I ue_ i ntege r_1 | 

[13] Va) ue_i nteger_1 | 

[15] Va I ue_ i n t ege r_1 J 

[16] Va I ue_i nteger_1 | 

[17] Va I ue_ i n t ege r_1 | 
[ 1 8 J Va I ue_ i n t ege r_t | 

[19] Va I ue_i nteger_1 | 

[20] Va I ue_ i n t ege r_1 | 

[21] Va I ue_ i n t ege r_1 | 

[22] Va I ue_ i n t ege r_1 | 


Ts ::= Va I ue_add ress_1 


Ns : := Va I ue_add ress_1 

Slot_time ::= Va I ue_ i n tege r_1 

^ ■ — P r i _t oken_ho I d_t i me := Va I ue_ i n t ege r_1 


Max_ac_4_rotat i on_t ime : Va I ue_i nteger_1 


Max_ac_2_ r o t a t i on_ t i me : := Va I ue_i nteger_1 


Max_ac_0_rot at i on_t ime : Va I ue_ i n t ege r_1 
Mac_r i ng_ma i ntenance_rotat i on_t ime : := Va I ue_ i nt ege r_1 
R i ng_ma i ntenance_t imer_ i n i t i a l_va I ue : := Va I ue_ i n t ege r_1 
Max_i nter_sol i c i t_count ::= Va I ue_ i n t ege r_1 


Mi n_post_s i I ence_preomb I e_l ength : :« Va I ue_ i nt ege r_1 
In_ring : := Va I ue_ i nteger_1 


Event_enab I e_mask : := EVENT_ENABLE_B I TS 


Max_ret ry_ limit : Va I ue_ i ntege r_1 

Ma_group_address : := SEQUENCE 
{ add r ess_no INTEGER, 

group_add Va I ue_add ress_1 

i 


Channe l_ass i gnments : Va I ue_i nteger_1 

Transmi 1 1 ed_powe r_ I eve l_ad j ustmen t ::= Va I ue_ i n t ege r_1 

T ransm i t ted_output_i nh i b i t s : := Va I ue__i nteger_1 



MI I ICD Prog ram 
ARCHITECTURE 


ORIGINAL PAGE IS 
OR POOR QUALITY 


Page 55 
21 July 1987 


Rece i ved_s i gna l_sources : := Va I ue_ i ntege r_1 
Signal i ng_mode := Va I ue_ i n t ege r_1 


Received_signal_level_report ing : := Va I ue_ i n t ege r_1 
Lan_topo I ogy_type : := Va I ue_ i nt ege r_1 


F r eeze_moc : = Va I ue_ i ntege r_1 
Mac_type : := 04h 


St atus_t ype : := CHOICE 
) unde f i ned_e r ro r 
success 

ref use_t o_comp I y 
nonsupported 
e r r o r_ i n_p re f o r 
not_ava i I ab I e 
bad_pa rame t e r_ i d 
bad_pa rameter_opererat ion 
bad_pa ramete r_va I ue 
bad_expec t ed_va I ue 


[0] Va I ue_ i n t ege r_1 

[1] Va I ue_i nteger_1 

[2] Va 1 ue_ i nt eger_t 

[3] Va I ue_ i n t ege r_1 

[4] Va i ue_i nteger_1 

[5] Va I ue_i nteger_1 

[6] Va I ue_ i nt ege r_1 

[7] Val ue_ i nteger_1 

[8] Val ue_i nteger_1 

[9] Va I ue_ i ntege r_1 


i 


Event_types : : = IMPLICIT SEQUENCE 
| event_c I ass Event_c I ass_types | 


EVENT_CLASS_TYPES : := CHOICE 
$ local [0] Event_ i dent i f i e r_types 

remote [l] Event_i dent i f i er_types 


Event_ident i f ier_types ::= CHOICE 
{ !ow_ici_mem 
I ow_pdu_mem 
dupl i cate_address 
faul ty_transmi tter 
xmi t_queue_t h resho I d_exceeded 
rece i ve_queue_threshol d_exceeded 
watch_dog_t imeout 
t oken_ lost 
dua l_token 

max_retry_encountered 
bad_message_sen t 
ns_nu I I 
ns_changed 


[0] Value_integer_1 

[1] Va I ue_ i nteger_1 

[2] Va I ue_ i nteger_1 

[3] Va I ue_ i nteger_1 

[4] Va I ue_i nteger_1 

[5] Va I ue_i nteger_1 

[6] Va I ue_ i n t ege r_1 

[8] Va I ue_ i nteger_t 

[9] Val ue_i nteger_1 

[10] Val ue_i nteger_1 

[11] Va I ue_address_1 

[12] Va I ue_ i n t ege r_1 

[13] Va I ue_ i nteger_1 


Event _enab I e_b i ts 
| low_ici_mem 


BIT STRING 


( 0 ). 
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I ow_pdu_mem . ( 1 ) _ 

dup I i cate_address (2), 

f au I t y_t ransm i t ter (3), 

xmi t_queue_threshol d_exceeded (4) , 
rece i ve_queue_thresho I d_exceeded (5) , 
watch_dog_t imeout (6), 

token_l ost ( 8 ) , 

dua l_token (g) _ 

max_ret ry_encount e red ( 10 ), 

bad_message_sent (11) 

ns_changed (12), 


(13)| — 1 is enabled 


Act i on_va I ue_t ypes : := CHOICE 


$ reset 

[ 0 ] 

Va 1 ue_ i ntege r_ 

Operot i on_command_types :: 

= CHOICE 

\ test_« 

[ 0 ] 

Dummy_ rw_ t y pe s 

t es t_» 

[1] 

Dummy_ rw_t ypes 

test_= 

[2] 

Dummy_ rw_t ypes 

test_<> 

[3] 

Dummy_rw_t ypes 

II 

V 

i 

in 

[4] 

Dummy_rw_t ypes 

t es t_>= 

[5] 

Dummy_rw_ types 

«_g i ven_constant 

[6] 

Given 

»_g i ven_constant 

IN 

Given 

=_g iven_constant 

[8] 

Given 

<>_g iven_constant 

[9] 

Given 

<=_g i ven_constant 

[ 10 ] 

G i ven 

>=_g i ven_cons tant 

[11] 

Given 


Given : : 

= CHOICE 

\ [0] 

Vaf ue_integer_1 j 

[1] 

Va 1 ue_address_1 { 

Constant 

: Val ue_i nteger_1 


\ 


Va I ue_ i nteger_1 : :® ILLICIT INTEGER 

Value_address_1 : IMPLICIT Long_word (32 BITS) 

Va I ue_add ress_1 6 : IMPLICIT ARRAY OF 16 Long„words 

(32 BITS EACH) 
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3.12 Mil OPERATIONS 

Although the actual process of initialization is not defined 
by the Mil, it is outlined below. 

1) The SM passes to the MAC (after checking the SM_RDY 
semaphore) a message which contains a pointer to a linked 
list of memory blocks suitable for the ICI information. 

2) The SM passes to the MAC (after checking the SM_RDY 
semaphore) a message which contains a pointer to a linked 
list of memory blocks suitable for the PDU information. 

3) The SM passes to the MAC (after checking the SM_RDY 
semaphore) a pointer to a linked list of memory blocks 
containing ASN.l records which; a) tells the MAC the address 
of the SM receive channel (SM_REC) and semaphore (SM_RDY); 
b) request the MACs Status and type; c) and if appropriate 
puts it on line; all in a single linked list of commands. 
This also could be done with a series of single messages to 
the MAC. 

LLC Initialization 

The LLC initialization is beyond the Mil scope except to say 
that the LLC must be made aware of the LLC_RDY semaphore and 
LLC_LINK locations. 

OPERATIONS -Indicate 

The SM operations with the MAC are no different than 
described under initialization. Each SM command has a 
unique link. Each SM command has a reply which overwrites 
the original command (the command record size is always 
larger than the reply). The reply indicates to the sender 
that it is now allowed to use that ICI memory block again. 
This way ICI can be passed back and forth without the need 
to request more blocks from the system. ICI information may 
include pointers to the PDUs and therefore a ICI reply also 
returns the PDU memory block to its original source. 

When a PDU arrives from the media the MAC arbitrates for the 
bus and begins data movement to common memory using one of 
the free blocks of memory. The MAC design may or may not 



Mil ICD Program 
ARCHITECTURE 


Page 58 
21 July 1987 


buffer the data going into the common memory. if 
the MAC is the highest level priority on the VMEbus then a 
biock mode operation will support the bandwidth necessary 
for no MAC buffering. These are design issues for the 
system designer. There are power, weight and speed 
advantages to no buffer MACs , however consuming the system 
bus for the length of one or more data packets may be 

unacceptable. The Mil does not restrict the system in these 
are as . 


Once the data is located in common memory the pointer to 
his PDU memory record and its size are included in a ASN.l 
message known as MAJDATA . indicate . The MAC performs 
and SET operation on the LLCs MAC_RDY semaphore. 

Test indicates the bit was set , then the LLCs MAC 
was already busy and the set operation did nothing, 
case the MAC must wait. The MAC will continue to TEST 
SET until the test indicates the busy bit was reset . 


a TEST 
If the 
channel 
In this 
and 
The 


bit has already been set so the MAC is now allowed to use 

[Tiie P° inter t0 the ICI which is an encoded 
MA_DATA. indicate is written into the location following the 
semaphore. This indicates the presents of incoming data to 
the LLC (See IEEE 802.2).] 


Once the MAC gains control over this channel it writes the 
pointer to the ICI (ASN.l MA_DATA . indicate) record into the 
LLCS MAC_LINK location. When this location is written to 
c 1S interrupted . The LLC uses the address to find 
the ICI record and it points to the address of the PDU data 
located in common memory. The LLC will then queue the 
pointer, link the ICI record to an existing linked list (of 
previous ICI records) and frees the channel as soon as 
possible. LLC now holds the pointer to the ICI and PDU 
memory blocks. 


The ICI memory (with the ASN.l record in it) is then 
overwritten with a indicate acknowledge record (also ASN l) 
and passed back to the MAC. The ICI also contains a pointer 
to the associated PDU. This allows the MAC to replenish its 
stock of free PDU blocks. The LLC and above layers must be 
finished with the PDU memory block before it sends the 
Indicate acknowledge primitive. 

OPERATIONS -Request 

A MA_DATA. request primitive is generated by the LLC to tell 
the MAC there is data to be shipped. This ASN.l record is 
put into a ICI memory block, the LLC__RDY semaphore captured 
and the pointer to the ICI block written to the LLC_LINK in 
the MAC. The MAC ships (or copies) the data, overwrites the 
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block with a MA_DATA . confirm and passes it back to the 
LLC via the MACJRDY semaphore and MAC_LINK locations in the 

LLC. The LLC can now replenish its stock of free ICI and 
PDU memory blocks. 


i 



